Spring Cloud | Note-9

发表于

Spring Cloud微服务 | Note(9)

@ 2018年8月15日 10:19:40

微服务——熔断机制

当服务过载，流量激增，超过负荷时，掐断服务，保护服务的机制；

什么是服务的熔断机制

对于系统的防护机制，不会导致服务的不响应，返回默认值，依然保持服务的响应；

对该服务的调用执行熔断，对于后续的请求，不再继续调用该目标服务，而是直接返回默认值，从而快速释放资源；保护系统；

熔断的原理（服务熔断）

断路器：受保护的服务封装在断路器中，当故障达到阈值时，切断服务的响应，由断路器返回响应；

断路器模式：防止应用程序执行可能失败的操作，使应用程序检测故障是否解决；

Microsof Azure 断路器状态：关闭，打开，半打开；

Hystrix：服务正常，服务异常（Fallback）；

熔断的意义

好处：保护系统，系统稳定，减少性能损耗，及时响应（简单的响应），阀值可定制；

功能：异常处理，日志记录，测试失败的操作，手动复位，并发，加速断路，重试失败请求；

熔断与降级的区别

相似：目的一致（可用性，可靠性，保护系统），表现类似（服务暂时不可达），粒度一致（服务级别，DAO）

区别：

​ ·触发条件不同——熔断由服务引起，降级由整体负荷引起；

​ ·管理目标层次不同——熔断管理整个框架级，每个服务都需要，降级管理业务层次；

如何集成Hystrix
1
2
3
4
// 依赖
dependencies {
	compile('org.springframework.cloud:spring-cloud-starter-netflix-hystrix')
}
1
2
3
4
5
6
7
8
9
10
// 启用
@SpringBootApplication
@EnableDiscoveryClient
@EnableFeignClients
@EnableCircuitBreaker
public class HystrixApplication {
	public static void main(String[] args) {
		SpringApplication.run(HystrixApplication.class, args);
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 服务过载时实现
@RestController
public class CityController {
	@Autowired
	private CityClient cityClient;
    
	@GetMapping("/cities")
	@HystrixCommand(fallbackMethod = "defaultCities")
	public String listCity() {
		// 通过Feign客户端来查找
		String body = cityClient.listCity();
		return body;
	}
	public String defaultCities(){
		return "服务暂不可用(City Server Is Down)";
	}
}
实现微服务的熔断机制
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 具体服务中实现熔断
@FeignClient(name = "micro-weather-eureka-client-zuul",fallback = DataClientFallback.class)
public interface DataClient {...}

// Bean
@Component
public class DataClientFallback implements DataClient{
	@Override
	public List<City> listCity() throws Exception {
		// 默认响应信息
        ...
	}

	@Override
	public WeatherResponse getDataByCityId(String cityId) {
		// 默认响应信息
		return null;
	}
}

// application.properties
spring.application.name=micro-weather-eureka-client-feign-gateway-hystrix
feign.hystrix.enabled=true

微服务——自动扩展

什么是自动扩展

垂直扩展（双核主机 –> 四核主机）硬件升级，瓶颈在于硬件水平的技术；

水平扩展（1台主机 –> x台主机）能力扩展，分布式系统解决计算能力；

自我注册和自我发现是自动扩展的前提条件；

服务注册表（服务注册中心），客户端，微服务实例；

客户端查询服务注册表，查询可用的服务；服务实例启动后，自我注册到服务注册表中，待客户端使用；

按需扩展：微服务实例分为使用中和保留，当需要更多实例时，再启动保留的服务实例，按照请求的需要扩展；

自动扩展的意义

解决应用程序为了支持长时间的运行，需要提前预留硬件、软件的功能，解决闲置资源的浪费问题；

按需扩展；

每个微服务实例需要独立的部署空间；

好处：

提供高可用性和容错能力：快速自动扩展使用新的服务实例，以满足服务的需要；

增加可伸缩性：水平扩展能力的增加，允许根据流量自动选择服务的规模；

具有最佳使用率，节约成本：按需扩展；

优先考虑服务或服务组：通过优先级分配资源；

自动扩展的常见模式

应用程序级别

扩展通过复制微服务实例实现，虚拟机或主机运行微服务；

更换服务实例；

基础架构级别

根据需求及时创建或消除；

保留的服务实例，被创建为具有预订意义的，服务实例虚拟机镜像，当有服务A的需求时，虚拟机将服务移动到激活的状态；

更换服务虚拟机，适用范围更广；

缺点：基于整个虚拟机扩展，体积更大，占用更多的系统资源；

解决：采用轻量级容器docker，减少资源的占用；

资源限制

监控程序：实时监控CPU的使用率，当使用率大于阀值时，启动新的服务实例；

特定时间段

根据特定时间段、季节性、业务高峰的服务需求，启动新的服务实例，减轻服务器的负载；

消息长度

监控程序监控每个服务实例的消息队列的长度，当队列长度大于设置的长度时，说明需要处理的消息超过服务可提供的能力，则新增服务实例；

业务参数

添加实例基于某些业务参数，解决业务事件时，通过先新增服务实例的方法，预防即将到来的大量业务交易请求；

根据预测

新型的自动扩展方式；

有多种信息事务模式的组合；

有助于解决硬编码和时间窗口；

根据历史信息，当前趋势进行预测（更精确，更有效的解决突发情况）；

如何实现微服务的自动扩展

思考的问题

如何管理数千个容器？

如何监控容器？

在部署工件时，如何应用规则和约束？

如何利用容器获得资源效率？

如何确保至少有一定数量的最小实例正在运行？

如何确保依赖服务正常运行？

如何进行滚动升级和优雅的迁移？

如何回滚错误的部署？

所需功能

依赖两个关键功能：

1-一个容器抽象层，在许多物理或虚拟机上提供统一的抽象；

2-容器编排和初始化系统在集群抽象之上智能管理部署

容器编排

为开发以及架构团队，提供一个抽象层，来处理大规模集装箱式的部署；

共同功能：具备发现、资源管理、监控和部署等；

职责：集群管理（将虚拟机和物理机器的集群管理为一台大型机器 ）

自动部署（能处理有大量及其的应用程序和容器的自动部署，支持多版本的应用程序容器，并且支持跨越大量集群机器的滚动升级和故障回滚）

可伸缩性（支持服务实例的自动和手动伸缩，以性能优化为主要目标）

运行状况的健康（管理集群、节点和应用程序的健康）

基础架构抽象（开发人员不需要担心集群和容量等问题）

资源优化（以有效的方式在可用机器上分配容器工作负载，从而减低成本，通过简单到复杂的算法有效提高利用率）

资源分配（基于应用程序开发人员设置的资源可用性和约束来分配服务器）

服务可用性（确保服务在集群中正常运行，机器故障的情况下，容器编排会自动通过在集群中的其他机器上重新启动这些服务来处理故障）

敏捷性（敏捷性工具能够快速分配工作负载到可用资源，或在资源需求发生变化时跨机器移动工作量）

隔离（提供资源隔离，即使应用程序不是容器化，也可以实现资源隔离）

资源分配常用算法

传播（Spread）工作负载平均分配到多台主机中；

装箱（Bin Packing）优先试图填满机器的最大负载，常用于按需付费的云服务；

随机（Random）工作负载随机分配到多台主机中；

常用的容器编排技术

Docker Swarm

Kubernetes

Apache Mesos

附录

@ 2018年8月15日 14:57:54